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ABSTRACT 



The Joint Deployment System (JDS) forms the junction 
among deliberate planning, time-sensitive planning, and the 
deployment of forces. The WWaccs Intercomputer Network 
(WIN) supplies the necessary interconnectivity among the 
joint deplcymen* community computer systems. In January 
1982, the WWMCCS Information System (WIS) modernization 
program was launched with objectives including the mcderni- 
zaticn of WWMCCCS hardware and software and the transfer 
from the present WWNCCS network system to the Defense Data 
Network (BDN) . Because C'f proven win unreliability, the JDS 
required site-unique software development to supplement 
present WIN software. 

Individualized application software, integrated with the 
improved network reliability and survivability of the DEN, 
will enhance the present C3 system. This thesis demcns- 
trates that the total implementation of the Wis involves 
additional modifications in site-unique applications, stand- 
ardized procedures for software development, updated 
hardware technology, and a multi-level security system. 
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I. INTRODDCTIOH 



A. PDBPOSE 

In the late seventies time-frame, ~he Joint Deployment 
Agency (JEA) experienced unsatisfactory WSMCCS Intercomputer 
Network (WIN) reliability for large data transfers to remote 
sites. Ihe WWMCCS Information System (WIS) modernization 
program addresses the WIN deficiency issues of power 
supplies and multi-level security and proposes changes in 
the WWMCCS network tc allow greater interconnectivity among 
sites . 

This thesis attempts to assess the WIS moaerniza tier, 
impact cn large software systems in the WWMCCS community, in 
particular, the Joint Deployment System (JDS) . Specific 
deficiencies in areas of hardware and software, surviv- 
ability, and management will be addressed and planned 
improvements analyzed. The mede rnization program should 
improve computer int erccnnectivity among the joint deplcy- 
ment community in the future, but the command-unique 
software and WWMCCS standard software modifications will 
provide the operational reliability necessary for operations 
in the interim. With the conglomeration of subnetworks into 
the Defense Data Network during the 1983-1986 time-frame, 
plus the future WIS support of these command-unique software 
applications and the improved WWMCCS Network, the joint 
deployment community may experience a more reliable system 
for computer resource sharing. 
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BILITifiY C3 NETiOBK 



Tbs Worldwide Military Command and Control Systsn 
(WMMCCS) of the United Statss centers around the needs of 
the National Command Authority (NCA) . A Command, Control 
and Communications (C3) process can be considered an uncer- 
tanity reducing technique which aids the commander in the 
control of forces. A good C3 system must permit the secure 
and timely flow of information to points both inside and 
outside the Department of Defense (DOD) . This flow must 
exist during all scenarios -- day-to-day activities, crises, 
conventional conflict, and nuclear war. The C3 system is a 
major ingredient to the U.S. national goal of deterrence of 
war. [ Ref. 1: p. 53 ] 

Using WWMCCS, the NCA communicates its desires for 
deployment of military forces to the Joint Chiefs of Staff 
(JCS). In short, the JCS mission can be defined as the 
execution of national decisions. This mission is supported 
by various communications networks and command and control 
systems, one of the icst central being the Joint Deployment 
System (JCS) which provides a bridge between the deliberate 
planning process and time-sensitive planning and execution. 
Connectivity for these systems is provided by the National 
Military Command System (NflCS) which consists of three 
command centers: the National Military Command Center 
(NMCC) , the Alternate National Military Command Center 
(ANMCC) , and the National Emergency Airborne Command Post 
(NEACE) . Also included in the NMCS are the various 
personnel and equipment necessary for adequate control of 
forces. [Bef. 2; p. 36] 

The Defense Communications System (DCS) is the founda- 
tion fcr worldwide communications during both peacetime and 
crisis situations. The DCS covers the United States, 

Europe, and the Pacific area with networks such as the 
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Automatsd Voice Network (AUTOVON) , rhe Automated Secure 
Voice Network(AUTOSEVCCOM) , and the Automated Digital 
Network (AUTODIN). WWIICCS was asrablished in 1962 and 
supports the command functions of the NCA by supplying 
information through an online data base system. Although 
communications is a fundamental aspect of a C3 system, 
simply having good communications does not equate to an 
adequate command, control, and communications system. The 
proper balance of command and control and ccmmunrcatio ns, in 
union with forces, results in maximum force effectiveness. 
[Ref. 3; p. 40] 

c. awMCcs 

WKMCCS evolved in the early 1960 's from a loosely knit 
conglcmerat icn of about 158 computer systems, using 30 
different software systems, and operating at 31 locations*, 
all serving the JCS, Unified and Specified commands, and the 
Service commands. The majority of these systems were devel- 
oped independently, consequently the lack of 
int ercperabilit y within the total system proved detrimental 
to its meeting the NCA requirements for inter communica tions 
among sites. As the concepts of C3 grew, additional 
requirements were demanded of the system; these requirements 
were met sporadically, and by 1970, there was an evident 
need for a UWHCCS modernisation effort. In June of 1970, 
the WHMCCS Automated Data Processing (AD?) Program was 
initiated to improve WW.^CCS support. The program’s goals 
included : 

(1) reduction of cost through standardized hardware 
and software 

(2) development of a viable Data Base Management 
System (DBMS) for data retrieval 

(3) standardization of data formats 



10 



(4) ce?.rrali Action of aanage m-srio activioies [Ref. 4: 
F. 2] 

Prior to this effort, the MMMCCS program had no centra], 
authcriry for its budgeting or manageraenr. Numerous organi- 
zations were responsible for the various aspects of the 
program; for instance, the WWMCCS Council provided policy 
guidance for development and operation of the system; th<= 

JCS evaluated WWMCCS ' overall e f fecri veness ; various 
assistant Secretaries of Defense provided advice on sysrem 
design and development, warning and intelligence matters, 
and aCP procurements; and each service was responsible for 
funding its equipment acquisition and sofrware deveiopoient . 
The WHMCCS System Engineering Office (MSEO) , a separate 
organization in the Eefense Communications agency (DCA) , was 
organized in the mid 1970's to coordinate the general system 
engineering of WWMCCS. One of the biggest disadvantages to 
the WWMCCS management structure was that the Director CC?, 
also Director, WWMCCS Engineering, reported to two 'organisa- 
tions: the assistant Secretary of Defense (C3I) for 

organization and technical matters and the chairman cf th-=- 
JCS for doctrine, operational policies, and validation of 
requirements. This, compounded with the fact that the 
Director, DCa, had no authority for the budgeti.ng cr manage- 
ment of the WWMCCS program, precluded the successful 
coordination of WWMCCS aOP development efforts. [Ref. 5: p. 
8 ] 

The WWMCCS aoP Program also outlined a set of well- 
defined requirements which included the capability to 
process large amounts of data within a reasonable time, 
reliability greater than 99%, user and maintenance friendli- 
ness, and small physical space and personnel requirements. 
[Bef. 6: p, 22] 
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The WWMCCS functicns which supporz related aissicns are 
grouped to allow each family of functions to be indepen- 
dently defined and i nplemen ted. Interfaces among the 
functional families are well defined. One of the basics of 
the WHMCCS architecture is the concept of four disiiinct 
functional families which support the SCA, JCS, and Unified 
and Specified Commands. They are: 

(1) Resource and Unit Monitoring (RUM) 

(2) Conventional Planning and dxecutior. (CPE) 

(3) Nuclear Planning and Execution (NPE) 

(4) Tactical Warning/Attacic Assessment and Space 
Defense (TW/AA and SD) [Ref. 7: p. 1-1] 

In addition, WWMCCS ADP is divided into three catego- 
ries. Category A includes the wwMCCS standard software, the 
backbone of WilMCCS ADP which principally supports ''.he 
command and control requirements. Category 3 is t'lat soft- 
ware which is unique to a particular activity. And Category 
C encompasses the newly emerging systems. [Ref, 8: p. 2] 

As WWMCCS grew, utilization of the wwMCCS Xnte cccmput er 
Network (WIN) increased. The network was initiateJ as a 
prototype at three sites and from 1977 to 1983 the number of 
WIN sites jumped frca six to twenty- three , with future plans 
eventually including all WWMCCS sites. Comncnly used func- 
tions include: 

(1) maintenance of status and location of forces and 
resources 

(2) planning for force mobilization and deployments 

(3) preparation of the Single Integrated Operations 
Flan (SIO?) 

(4) estimating and monitoring Navy fleet fuel 
consumption 

(5) assisting in preparation and processing cf 
AUTODIN messages [Ref. 9: p. 5] 



12 



The utilization cf the Joint Caployaent System (JDS) 
contributed to the increased activi-.y on the MWMCCS network. 
As a piimary function, the JDS maintains Time-Phased Force 
Deployment Data (TPFDD) files for specific Operation Plans 
(OPLANs) outlining the supported commander's concept of 
cperaticns and requirements. [ 5ef . 10: ;?• 11] Prior to 
additional software development, these files were sent to 
WIN subscribers in their entirety to initiate JCS exercises. 
As the TPFDD files were updated throughout the exercise, the 
entire file was again sent to all users. These large data 
transfers, coupled with an overall increise in WIN usage, 
placed a burden cn network componer\s and host processors, 
causing WIN performance to reach an ansa cisfactcry level. 
Particular site-unique development included the JDS Hemcte 
User's Package (HUP) , discussed in Chapter 3. 

A new surfacing problem was the lack of a Multi-Level 
Security (MLS) systen. A MLS system allows users with 
varying security clearances to simultaneously share ccmputar 
equipnent with access tc various software allowed on a 
case-by-case security check. One theory for implementing a 
MLS system is the usage of rings of protective organization 
for the hardware. Here, the operating system is segmented 
into N-rings, with N greater than tv:o. The inner-most ring 
will be cccupied by the core, or kernel, of the operating 
system. The system software and security processes will be 
run here; for instance, validation of passwords and data 
access requests. The resource allocation software should 
reside in a separate ring for scheduling of tasks and 
computer resources. The outer rings are available to the 
users for processing application programs. Routines in Ring 
'i' have access to Rings 'i' and all rings greater but can 
only access more inner rings through procedure calls, thus 
affording the proper security check opportunity. The rings 
cf prctecticn secure sensitive software and data ana also 
act as firewalls against user damage. [Ref. 11: p- 540] 
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It is interesting ro note that in the mid-1960*s the 
Massachusetts Institute of Technology, Bell Telephone 
Laboratories, and the computer department of the General 
Electric (GE) Company developed one of the first operating 
systens tc employ rings of protection, the Multiplexed 
Information and Computing System (MULTICS) . The original 
MULTICS was installed on a GE6U5, later a Honeywell 
Information System (HIS) 645 computer, and in 1973, replaced 
by the HIS 6180. The HIS 6130 supports eight rings of 
protection: the operating system uses Rings 0-3; Rings 4-7 

are available tc the users, [Ref. 11: p. 535] With no L1LS 
system, all machines, terminals, and personnel on the WIN 
must be cleared to the highest level being utilized. 

[Ref. 12: p. 7] 

ether problems included the lade of a long-range plan 
for WHMCCS/WIN development and the early 1960 Honeywell 
architecture which is not the state-of-the-art fer an online 
query and response system. 

A misconception was also prevalent concerning WWMCCS — 
that it would provide communications between the President 
and the foxhole. This was never the design intention of 
WWMCCS; however, what was desired was a communications 
network for several cemmaui echelons and a reliable military 
command and control system connecting the NCA to the 
executing cemmanders. [Ref. 1: p. 40] 

Although the reliability of the WWMCCS Intercomputer 
Network (WIN) had fallen below a satisfactory level, tae 
WWMCCS AEF sites utilized the on-site Honeywell computer 
equipment tc develop software applications for unique 
requirements. By the mid 1970's, there was a great depen- 
dency cn WWMCCS ADP for day-to-day operations and 
crisis/exercise support and the need for a reliable computer 
network became obvious. [Ref. 12: p. 7] 
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^2:. 8BMCCS INFORB ATIO N 



A. BACKGROUND 



lE Ncvsmfcsr 1931 <. the Deputy Secretary of Defense 
decided the WWMCCS Information System (WIS) mode rn izaricn 
plan needed a focal pcim; for coordination to receive policy 
and guidance directives lirom the JCS . In January 1982, a 
WIS Joint Program Manage:: (JPM) was appointed to control nhe 
joint modernization activities of WWMCCS ADP an i the devel- 
opment of all telecommunications interfaces. Small 
site-unique enhancements will continue to be processed 
normally. The HIS JPM receives direction from the JCS and 
reports through the JCS to the Secretary of Defense. 

[Ref. 8: p. 44] 

A System Progaai office (SPO) was established within the 
Air Force Electronic Systems Division to manage WIS acquisi- 
tion and provide support in such areas as architecture and 
system encineering. The SPO also maintains Air Force 
programming and biidgetin; data for the WIS modernization 
plan. [Ref. 8: p. 44] T ne Director, DCA and the wis JPM 
have signed a Meiorardum of Agreement which specifies the 
guidelines for the Command and Control Technical Center 
(CCTC) support to the HIS modernization effort. 

The basic goal for the WIS modernization program is to 
provide the NCA, JCS, and Unified and Specified commanders 
with real time access to status and warning information. 

HIS objectives include: improved WWMCCS performance, 

greater WIN reliability, modernization of WWMCCS ADP harware 
and software, and increased ADP security. Of the three 
WWMCCS AEF categories mentioned previously, WIS will 
centralize its effort on Category A -- WWMCCS standard 
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sofrwars. Cf the four functional families of operational 
requirements, WIS will focus only on two: Resource and Unit 

fionitcring (ROM) and Conventional Planning and Execution 
<CPE) . The Air Force will continue to manage the WWMCCS AD? 
systeES in the Nuclear Planning and Execution (NPE) and 
Tactical Karning/Att ack Assessment and Space Defense (TW/AA 
and SE) areas. [Sef. 8: p. 18] 

E. SISTEH DESIGN 

The iiJVJHCCS Information System (WIS) was designed as an 
interactive network system in which a user at any command or 
agency can ccmmunicate with a user/host at any other command 
or agency also connected to the network. The Defense Data 
Network (DDN) >ill provide the interconnection among WWMCCS 
sites. A Network Operations Center will monitor the network 
as a separate node on the DDN. Local area networks (LANs) 
will exist for secure and interactive communications. The 
advantaces to LANs include: usual ease in configuring 

systems to meet specific site requirements, development of 
standard components for common functions, flexibility for 
selective modei'n izat ion, and the ability to develop incre- 
mental security solutions. Figure 2.1 graphically depicts 
the user support scheme envisioned by WIS. 

[Eef. 8: p. 3] 

The WIS system objectives include: 

(1) user-friendly interface development 

(2) data processing capabilities fcr all WWMCCS 

£1 1 

(3) reliable int er- command communications 

(4) improved processing capabilities during battle 

conditions [ Hef . 8: p. 15] 
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Figure 2.1 User Support Overview. 
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Proj€Ct€d WIS character istics to accomplish these goals 
are divided into three categories: access, availability, and 
modularity. 

access characteristics: 

(1) organic SIS support for major sites 

(2) remote access capability for small sites 

(3) user access from a single work station 

(4) a multi-level security system 

(5) minimum site training requirement 
Availability characteristics: 

(1) secure and interactive network 

(2) operational for day-to-day and crisis suppor* 
Modularity and flexitilty characteristics: 

(1) accomodation of a wide range of sites 

(2) standard software 

(3) minimum implementation disruption 

(4) state-of-the-art technologies considered 
[fief. 8: p. 16] 



C. SISTE8 STROCiaRE GOIDELINES 

The WIS JPM Office has developed guidelines for WIS 
system requirements in the areas of standardization, 
security, and system charac terist ics . 

Hardware standardization will not be mandatory because 
of the numerous existing systems and the competitive 
procurement possibilities. Software development standardi- 
zation will be achieved through the exclusive use of ADA as 
the program design language. Standard, ore-determined 
protocols will set the intercomputer communications stan- 
dards. Routine and emergency maintenance will be monitored 
by a single organization; maintenance standards will be 
imposed. To facilitate cooperation among the remote sites, 
data definition standards will be implemented. [Ref. 8: p. 
31 ] 
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The core of -the WIS security program lies in the tnulni- 
level secure LANs with secure interfaces to all orher Wis 
components. Autbent icar ion for users will be applied as a 
security control with an audio capability available. DCD 
security requirements require that a multi-level security 
system be achieved within the WIS modernization program. 
[Ref. 8: p. 34 3 

The WIS modernization program will provide capabilities 
to improve communication survivability and AD? support to 
WWMCCS sites. Seme proposed capabilities are: 

(1) distributed and/or redundant processing with 

remote access 

(2) graceful degradation 

(3) rapid restart and recovery 

(4) distributed data files 

(5) transportable systems 

Standards for accessibility include the ability to 
access all WlS-related capabilities from a single worksta- 
tion. Other required system capabilities are flexibility, 
reliability, maintainability, and interoperability. 

[Hef. 8: p. 35] 

D. lEPLEBENTATION 

WIS will be implemented during four modernization 
segments and utilizing four major contracts. The 
Maintenance Segment includes the near-term enhancements to 
the baseline hardware and software to stabilize WIS perfor- 
mance and will be accomplished through the Integration 
Contract. Next, the Transition Segment, linked to the 
Common User contract, transfers the user communities from 
the existing WWMCCS ADP to the WIS modular architecture for 
future medernization and initiates the Automated Message 
Handling capabilty. The Joint Mission Segment concentrates 
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cn th€ commcn applications software modernization; the Join 
Mission Hardware contract will provide the standard hardwar 
tase and supporting operating system by late FY85. The 
final segment will be the Service and Command unique appli- 
caticn software improvements which will be the 
respcnsibility of the Services and user commands. Figure 
2.2 illustrates the HIS growth through the four moderniza- 
tion segments. [Hef. 8: p. 3] The last major contract, the 
Conf iguraticn Management contract, provides for independent 
validation of the software provided by the Integration and 
Common User contractors. In addition, this contractor will 
assist the HIS JPM in the overall configuration management 
of HIS. [Ref. 13: p. 9] 

E. EVALOSTICN/COMPiBISON EFFORT 

As mentioned earlier, one of the major problems in the 
WWMCCS community is the unsatisfactory performance cf the 
HWMCCS Intercomputer Network (HIM). In September 1981, 
Director, DCA organized an effort to investigate the 
replacement cf the present HWMCCS network system with a mcr 
contemporary system. 

Initially, the idea surfaced to take advantage of the 
proven AUTOCIN I technology and develop an AUTODIM II. It 
was envisioned that AUTODIN II would provide a common user 
data network with a lulti-level security system to meet 
network requirements through 1985. In 1976, the contract 
was awarded to Western Union, Inc. and the Initial 
Operational Capability (IOC) was set for January 1979. 

[Ref . 14 : p. 44 ] 
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tfIS Architectural Segments 



Eeginniig in 1979, the IOC date was extended ssvaral 
times until July 1980, when the Assistant Secretary of 
Defense fcr Command, Control, Communications and 
Intelligence (ASDC3I) requested a review of the AUTODIM II 
project with some possible alternative proposals. In July 
1981, the Deputy Onder Secretary of Defense for C3I 
(D0SDC3I) questioned the wartime survivability of AUTCDIN 
II. Ihe doubt focused on one of the basic design criteria 
for the system -- a small number of switching nodes. These 
switching nodes would require manning and would be rela- 
tively expensive. Immediately after this, the Air Force 
Test Director issued a report concerning the increasing cost 
of the system and doubts about the technology and future 
systei performance. [Ref. 14: p. 45] 

In late 1981 the Director, Defense Communications Agency 
(DCA) established three design teams: 

Team 1 -- tasked with designing the best possible, 
survivable AUTODIN II system 

Team 2 -- tasked with designing the best alternative 
which would be based on the ARPAN2T and WIN tech- 
nology, a Replica approach 
Team 3 -- a 30-day evaluation team. 

The evaluation team was to establisn guidance fcr the 
two design teams and develop evaluation criteria. [Ref. 14: 
p. 45] Seme of the evaluation factors considered were 
survivability, security, system design, and cost. The 
ARPANET replica proposal, referred to as the Replica, seemed 
better able to withstand network element losses, proposed a 
more flexible routing algorithm, and afforded a greater 
mobility capability. [Ref. 15] 

AUTODIN II now had a six-year old design and, because of 
continuous technology advances, the expected life of a 
computer system is about eight years. In the area of large 
data transfers, AUTODIN II was superior to the Replica 
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design. The Replica design would be using smaller packers 
for message transfers throughout the network — smaller 
packets necessitate more numerous packets which in turn 
increase the overhead traffic through the system and car 
degrade system performance. If AUTO DIN II had been avai- 
lable fcr i Bple menta tion during the evaluation effort time 
frame, the technology, schedule, and cost risks associated 
with the Replica proposal would certainly have cancelled 
some of the benefits. However, having no satisfactory 
AUTODIN II system online, the benefits of the Replica 
approach justified the risks. [Ref. 15] 

In constant FY82 dollars, AUTODIN II total system cost 
was estimated at $580 million where the Replica total system 
cost was $429 millior. It was projected that the AUTGCIN IT. 
annual operating costs would steadily increase to $72 
iiillicn until 1995, where the annual cost would level off 
near $55 nillion. The Replica system annual cost is 
expected to peak at $71 million around 1985 and steadily 
decrease to the $40 million range in 1987. Figure 2.3 shews 
DDN/Eeplica annual ccsts. [Ref. 15] 

In February 1982, the evaluation was completed. Based 
cn the conclusions the Director of DCA decided the Replica 
approach would provide a better DOD data network. 
Consequently, the Deputy Under secretary cf Defense erderef 
the termination of the AUTO DIN II network and tne initiali- 
zation of the Replica design, to be known as the Defense 
Data Network (DDN) . [Ref. 14: p. 45] 

F. DEFENSE DATA NBTBOEK 

The Defense Data Network (DDN) will provide the «IS 
community with the secure, reliable, interactive network 
necessary tc perform its functions. The DDN is designed as 
a single, integrated packet -switching data network. The 
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Figure 2.3 DDN/Replica Annual Costs <= 

cooiplscsd network will have 91 subscriber sysrems with 
approximately 488 hosts and 1 ,446 terminals. rher-i will be 
171 switching nodes at 85 sites. The DDN meats ^he 
Worldwide Digital System Architecture (WWDSA) standards and 
objectives by providing a solid technology base, low risk, 
and a cost effective system. This network will satisfy 
current survivability requirements during a crisis and meet 
COD intercomputer telecommunication requirements supplied by 
the JCS. [Bef. 16: p. 2] 

The major DDN design concepts are standardized compo- 
nents, distributed switching nodes, and automatic fault 
recognition. Standardized components allow smaller develop- 
ment costs and lower maintenance and support costs. Also, 
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compcnent modularity reduces the mai nrenance impact. 
Distributed switching nodes aid in sliiarnating choke points 
which increases the overall survivability of the system. A 
wide distribution of switching nodes usually mj.nimizes any 
impact after a single node failure. Another mc.jor concept, 
the DCN automatic fault recognition system, is implemented 
through a series of Monitoring Centers (MCs) which are in 
continuous operation to monitor network performance and 
identify trouble areas. 

The network Monitoring Centers will be key nodes on the 
DDN network. There will be a principal system MC, an alter- 
nate MC, regional HCs for Europe and the Pacifi.c area, and a 
MC for each keyed community. Primary functions: for the 
monitcring centers will include: 

(1) monitoring the status of the network 

(2) isolating network faults 

(3) supporting software maintenance 

(4) providing network element infO'.tmat;.on [Ref- 16; 
p. 5] 

The Defense Data Network will provide four levels of 
support to the current WHMCCS community: 

Level 1 — host processor sites fcr Resource and 

Unit iMonitoring (RUM) and Conventional Planning and 
Execution (CPE) support 

Level 2 — limited on-site processor support plus 
access to remote host processors 

Level 3 — processor support thronp'h network access 
tc remote processors in Hawaii 

level 4 — support through individual terminals 
connected to remote host data processors [Ref. 8: p. 
21 ] 

Tie Defense Data Network is designed for continuous 
operation tc support real time handling of all user's 
traffic. The availability goal is greater than 99^ for any 
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pair cf users. [Ref. 17: p. 5] The rhree major DDN system 
elements are switching nodes, IPLIs, and Mini-TACs. 

The switching node used for the DDN is a Bolt Beranek 
and Newman (EBN) C/30 switch, a microprogrammed minicoirputsr 
designed for unattended operations which eliminates the need 
for DEN dedicated personnel at each switching node. The 
throughput capability of each C/30 node is 300 packets per 
second in tandem processing — 300 packets in, 300 packets 
switched, and 300 packets out simultaneously, for a total of 
900 packets being handled. The long term reliability goal 
is 5000 hours or greater for Mean Time Between Failures 
(MTBF). The development risks are low since the C/30 switch 
and its software are functioning elements on such networks 
as the ARPANET; WIN; Community On-Line Intelligence Network 
(COINS); Intelligence Data Handling System, Ccmraunicaticns 
(IDHSC) ; and the Burcpaan Mcveme:'': Infcrmation Network 
(MINE!). Technology risks are coreideied low since only 
minor modifications are neccsssary. [Eef. 16: p. 33] 

The Internet Private Line Interface (IPLI) is based on 
the Private Line Interface (Phi) vr-’ich has been used on the 
ARPANET and Other networks for more than five years. The 
PLI/IFLI technology allows the simples*, of end-to-end 
encryption available. An ILPI will reside between a host 
and switching node or Mini-Terrair.ai Access Controller 
(mini-TAC) and switching node, depending on site configura- 
tion. The IPLI is currently under development with an 
initial delivery date of July 1983. It will support the 
standard COD prctoccl, Internet Protocol (IP), and widesp- 
read deployment is expected because of reduced cost, size, 
and power and weight requirements from the PLI currently 
teing used. The IPLI hardware consists of a KG-84 crypto- 
graphic device and two Motorola MC68 000- based packet 
processors. A minimum of fifty packets per second is set as 
a throughput goal and the MTBF goal is at least 5000 hours. 
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The ilean Tise To Repair (MTTR) is expected to be apcrcxi- 
mately thirty ainutes with an availability of 99.9^. The 
IPLI requires no additional personnel and the maintenance 
and mcnitcring systems may be operated from a remote site. 
The devclcpment risk involved :.s considered low due to the 
traditional architecture used. [Bef. 14 : p. 39] 

A Hini-Ier minal iccess Controller (mini-TAC) is a 
terminal access device which allows a cluster of up to 
sixteen terminals si irultar eous access to the network. The 
hardware of a mini-TAC is a MC(»8000 microprocessor with 
memory and multiple retwonk interface ports. The mini-TAC 
software is based on the software developed for use cn the 
ARPANET and allows terminal users to establish connections 
between their terminals and an arbitrary host on the 
network. The DOD standard I? and Transmission Control 
Protocol (TCP) are used. The I1T3F gcal is greater than 5000 
hours and the bo ard-swappin g capability simplifies mainte- 
nance. Since the mini-TAC is <ilso designed fer unattended 
eperatiens, no dedicated personnel are required. Control 
mcnitcring and hardware/software fault isolation can be 
accomplished remotely by the MCs. Mini-TAC availability is 
expected during FY84. [Ref. 16 : p. 42 ] 

Cne cf the major cof. par ison factors for the AUTOCIN 
II/DDN evaluation was survivability. The small number cf 
nodes preposed fer the AUTODIN II system left major doubt as 
to its survivability. DDN’s survivability features include: 

( 1 ) redundancy -- the final system will comprise 171 
switching nodes, 9 fixed monitoring centers, and 5 
mobile reconstitution nodes with MC capability 

(2) disseminated switching nodes -- geographically 
dispersed sites afford the higher priority users a 
greater chance of reconstitution 

(3) a dynamically adaptive routing algorithm which 
autemat ically reroutes traffic around heavily cong- 
ested or damaged links and nodes 
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j4) graceful degradation because of the network’s 
response to damaged nodes 

(5) four levels of precedence/pr eemption processing 

(6) hardening and HEMP prcrecrion including electro- 
magnetic shielding, line isolation, and power surge 
protection 

(7) reconstitution -- the five mobile reconstitution 
nodes will be positioned in areas less likely to be 
targeted and all users will have a detailed alterna- 
tive routing plan 

(S) preplanned rehoming — all users will have a 
priority listing of switching nodes for rehoming 

[Ref. 16: p. 125] 

DEN security will be accomplished through link encryp- 
tion, and-tc-end encryption, and physical and procedural 
security measures. The KG-84 cryptographic devices will 
provide the necessary link encryption. The Internet Private 
line Interface (IPLI) devices between the host and switching 
node cr mini-TAC and switching nods will provide the 
end-tc-end encryption. The IPLI will also separate subscri- 
bers operating at different system security levels. For 
physical sec’xcity measures, all switching nodes will be 
TEMPEST enclosed and located in secure military facilities. 
Only System Monitoring center (SMC) personnel will be able 
to retrieve traffic statistics. All personnel at regional 
and system MCs and personnel with access to switching nodes 
will hold a SECRET clearance. In addition, personnel with 
access to a MC for a secure subnetwork must also be cleared 
to the highest security level of the subnetwork subscribers. 
[Ref. 16: p. 12] 

The CEN program office is within the DCA organization 
and consequently comes under DCA's staffing and policies. 

The National Security Agency (NSA) has the responsibility 
for certifying and accrediting the IPLI devices and 
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analyzing the network system design for use wirh classified 
traffic. DDN subscribers will be responsible for acquiring 
the necessary hardware and software for DDN operation and 
support. [Hef. 14; p. 258] 

Another major factor considered during the evaluation 
phase was cost. According to the evaluation team, the *’DCN 
I system can provide COD with a survivable, common-user 
system at a cost less than being paid for the dedicated 
systems,..''. [Ref. 16: p. 15] Using FY32 dollars, the 91 
dedicated systems listed in the user requirement data bass 
cost ever $35.2 million for annual operation. The annual 
cost for the new DDN system includes; 



When development and acquisition costs are included, DDN 
annual operating costs average $35,549 million over a ten 
year period. [Ref. 16; p. 255] 

The Defense Data Network system design builds on three 
operational networks which use the B3N C/30 switching node 
and accompanying software: 



The DDN will employ a four stage implementation apprcach 
which should lead to a graceful evolution capitalizing on 
existing networks and interfaces with minimum risk for new 
technclogies. The ARPANET will supplement DDN’s test and 
development facilities but will remain as a sealed-dewn 
research network. It will later serve as an operational 
testbed for future DDN software releases. [Ref. 16: p. 24] 



System Management 
Trunk/Access Lines 
Operations and Management 
Total 



3,354 K (10.3??) 

2 4,6 94 K ( 7.6??) 

4,428 K (13.6=?) 

$32,476 K Annually 



(1) ARPANET — with 90 nodes at 75 locations 

(2) WIN — with 26 nodes at 16 locations 

(3) MINET — with European locations [Ref. 17; p. 2] 
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The four transition stages for DDN I are: 

Stage 1 — Service will be provided to subscribers chat 
can be handled with minimum development. The WWMCCS Network 
C/30 switch upgrade will be accomplished during this stage. 
Communities of interest and networks with differing security 
leve.‘ls will be physically separated into three distinct 
netwcrks : 

(1) Strategic Air Command Digital Network (SACDIN) 

— at a Top Secret (TSi system-high security level 

(2) Military Network (MILMET) — for unclassified 

subscribers to include military ARPANET users 

(3) Command and Control Intelligence (C2I) Network 

— with a TS system-high security level network with 

twc subnetwork communities: 

the C2 Community basically for WIN subscribers and 
the Intelligence Community primarily for IDHS 
II/Department of Defense Intelligence Information 
Systems (DCDIIS) users. 

Stage 1 is expected tc be completed by end of FY33. 

Stage 2 — As additional IPLIs become available during 
198U, more subscribers will be added to the network. The 
mini-TACs will be implemented in Stage 2 , also. Completion 
is expected by the end of FY84. 

Stage 3 — During Stage 3, the three separate networks 
originated during Stage 1 will be integrated to become the 
DDN I, supporting multiple levels of security. During this 
stage, additional classified subscribers will be inccrpc- 
rated into the network. Stage 3 will be completed by the 
end of FY85. 

Stage 4 — As host interfaces are developed, all 
remaining DDN subscribers will be included in the network. 
The final DDN I network will consist of 171 nodes supporting 
91 systems, and the DDN system design allows for a moderate 
increase in traffic from each network user. [Ref. 16: p. 
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189] Figure 2.4 shows the transition plan for the DDN I. 

[Ref. 16; p. 190] 

G. WIS/CCN CONNECTICN 

Currently, the Defense Communications Agency provides 
WWMCCS software support through the Command and Control 
Technical Center (CCTC) . Although the WIS modernization 
plan is not a part of DCA, the WIS JPM and the Director of 
DCA have entered a Memorandum of Agreement which insures 
CCTC support during the WIS modernization effort. However, 
since plans call for the Defense Data Network (DDN) to he 
integrated into the CCS, the DDN program office falls under 
the DCA organization. The DDN will provide a common user 
network, oapable of incorporating the majority of the C3 
networks available today and providing a standard, secure 
and shared-resource capability. 

The DEN will not he restricted to support of the WWMCCS 
community. As can be seen from Figure 2.4, networks such a 
the SAC Digital Network (SACDIN) and the ARPANET will 
utilize the Defense Data Network for intercommunications 
among member sites. With these various user communities 
riding on one network system, a multi-level security system 
is imperative, although technology hinders the development 
of such a system. The management of the DDN network, a 
network where users range from unclassified military users 
on the ARPANET to high classification users of the JDS on 
the WIN, has not been sufficiently addressed and will beccm 
the source of major problems. 

As DDN comes into being, new WWMCCS standard software 
will he implemented under the WIS modernization plan and 
existing site-unique software will be modified to reflect 
the updated system. These software changes and future hard 
ware acquisitions will affect every system used within the 
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HWMCCS ccmniuDity . The WIS modernization impact will be felt 
by all users supported by the Joint Deployment System (JDS), 
one of the most widely used WWiICCS systems and the total 
management system coordinating the links between deliberate 
planning, time-sensitive planning, and deployment of forces. 
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Figure 2.4 DDN Transition Plan 



III. JOIOT D EPL OY aSN T SYSTEM 



A. BACKGBODND 

In Cctober 1978, the JCS conduczed a command pos~ 3xer- 
cise, NIFTY NUGGET, tc test full mobilization and deploymeno 
capabilities for U.S. forces. NIFTY NUGGET exposed defi- 
ciencies in borh the military deployment planning and 
execution process as well as the supporting Management 
Inf or maticr. System (KIS) . The systems most widely utilized 
during NIFTY NUGGET included the Joint Operational Planning 
System (JCPS), Unit Status and Identification Report 
(UNITEEP) System, and command unique systems such as the 
Deployment Management System (DEPMAS) used by the U.S. 
Readiness Ccmmand (USHEDCOM). JOPS supported planning but 
supplied no support for the execution phase. The UNITHEP 
system was not responsive tc time-sensitive decisions. 

CEPHAS was not available to the joint deployment community, 
the system dealt with Army and Air Force forces only. ihe 
need for a centralized deployment and decision support 
system fcr planning and execution was evident. In March 
1979 , the Joint Eeplcyment Agency (JDA) was established tc 
support the JCS and supporting commanders as the nucleus of 
deployment and associated activities. [Ref. 10: p. 3] 

The Joint Deployment System (JDS) , resident at the Joint 
Deployment Agency, was created to support the JDA mission. 
Ihe JCS includes personnel, procedures, directives, communi- 
cations systems, and electronic data processing systems 
which support peacetime planning and time sensitive planning 
and procedures. The JDS concept is the development of a 
single support system for all stages of deployment manage- 
ment with particular focus on planning, deployment 



34 



execution, and crisis monitoring. After the JCS exercise 
order is delivered, the JDS allows the monitoring of mcve- 
menr of forces, materiel, and non-anir related personnel. 
The Master Force List (MFL) file, schedule file, scheduling 
requirements and UNITEEP data are generated from the deplcy 
ment data base and distributed to users. [Bef. 10: p. 18] 
Through the JDS, the Joint Chiefs can achieve direct imple- 
mentation of their deployment decisions during peacetime, 
command pest exercises, crises, and war. [Bef. 18: p^ 1] 

E. JCS/HIH LINK 

The mission cf the JDA obviously depends on interccnr.ee 
tivity ameng the joint deployment community. The MWMCCS 
Intercomputer Network (WIN) is used to organize these 
geographically separated host computers intc a single 
network and becomes the backbone of the JDS communications 
system, essential in the planning and execution of deploy- 
ment decisiens. The deployment data case depends on WIN fo 
accurate information exchange between user sites and the 
JDA. [Bef. 19: p. 1] Figure 3.1 illustrates the WIN rela- 
tionships within the joint deployment community. [Bef- 20: 

p. 12] 

Transaction throughput is site dependent but a JDA site 
will usually average 1200 transactions per hour. User 
response tiire is dependent on the number cf users simul-ane 
cusly accessing WIN. For example, with an average of ten 
simultaneous users, SIN response time averages two to five 
seconds. Ten is considered a small number of users and one 
ever ten, significant performance degradation is experi- 
enced. [Ref. 18: p. 13] The WIN software available for 
transactions include TELNET, the Telecommunications Network 
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Program usad for message exchange and direct acc=ss no 
resources of rsmcts hosts, the File Transfer Service (FTS) 
used mainly for large bulk transfers between sites (i.e., 
the TPFDD file and TPFDD fils changes), and the 
Taleccnf erence (TLCF) capability which simultaneously links 
any number cf MIN nodes into a textual exchange conf erencs'. 
AUTODIN is the general message exchange system which may 
also ke used for guery/responss activities and NACF trans- 
fers data between the JDS and AUTODIN, a utoraat ica 13.y 
formatting the messages generated by JDS. [Her. 'iO: p. 18] 

C. AEP GOALS AND CAPIBILITIHS 

The Joint Deployment System AD? criteria goals include 
an availability cf 24 hours a day, 7 days a week, except fcr 
scheduled maintenance and unexpected outages. The cfstraticn 
goal is S5^ for routine processing and 99 % for crisis and 
exercise cperations. The deployment data base is resident 
at JDA with the major backup at REDCON. The JDA and RFDCCl''. 
computer systems are comprised of four processors crgarized 
in dual ccnf igur at icr. with shared disk drives, colocated in 
the same facility. The JDS reliability goal for >!TB? is 36 
hours with ?1TTR cf 10 minutes. When fully develcped, JDS 
will be a transaction-oriented communica ti cns system capable 
of real-time processing on a distributed data base within 
the MIN environment. [Ref. 10; p. 32] 

The JDS computer system availability not only depends on 
the best computer up/dewn ratio; other factors include the 
supporting MMMCCS system software such as the Time-Sharing 
System (TSS) and the General Comprehensive Operating System 
(GCOS) , the JDS software which includes the Remote User’s 
Package (RUP), and WIN availability. All cf these ccratc- 
nents must be available for a remote user to access the 
deployment data base. JDS will allow interfaces with 
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appropriate service and com mand-unigu e dara systems for 
accurate information flow among the joint deployment 
comm unit y . 

The JDS is divided into 5 procedural subsystems: 

(1) plan generation — expansion of the data base 
fcr inclusion of new data 

(2) plan maintenance — modification of the data 
base to reflect changing resources or constraints 

(3) execution prepara-^ion — adjustments to clan 
data to account for real world dates and require- 
ments 

(U) scheduling -- coordination and distribution of 
transportation schedules developed in conjunction 
with the Tra rsporta ting Operating Agencies (TCAs) , 
i.e., Military Airlift Command (MAC), Military 
Traffic Management Command (MTMC), and Military 
Sealift Command (MSC) 

(5) movement monitoring -- reporting of the status 
of the deployment, departures, and arrivals 

[Bef. 10: p. 20] 

The Joint Deployment System offers the joint deployment 
comaunity five processing alternatives: 

(1) Time Sharing System (T3S) -- simultaneous access 
of the computer system by more than one user 

(2) batch updating -- primary system for JDS data 
base control 

(2) transaction processing -- data base updating 
through one of twenty-three Transaction Service 
Modules (TSMs) which mainrain a near real-time 
information flow between WIN sites 

(U) stand-alone programs — software sent over the 
WIN network to update the JDS data base 
(5) Bemote User’s Package (RU?) — provides the 
capability to send and receive transactions from 
other WIN sites [Ref, 21: p. 34] 
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Users may access local or remore deployment dara bases 
using any one of four methods. Twenty-two on-line queries 
are available on the time sharing system. The Management 
Data Cuery System (MEQS) for retrievals allows the user tc 
criginats a batch process for information retrieval from the 
Master Force List (MEL) file and schedule files. The MFL 
file also allows users without the RUP capability to 
initiate information queries. Users can also utilize the 
automatic scheduling messages package to automatically 
receive movement data for the next twenty-four hours through 
the NMCC Automated Control Executive (NACE) . [Hef. 21: p. 
65] 

D. DEVEIOPBEHT 

The Joint Deployment System is being developed in five 
stages. The Baseline Stage has been completed and JDS now 
provides service to the joint deployment community. The 
Initial Cperational Capability (IOC) for the second stage, 
which includes limited on-line update ana query features, 
distributed processing support via the Remote User’s Package 
(RUP), and data base backup at REDCOM, was achieved December 
1982. The third stage incorporates long-term requirements 
definition and validation. These additional requirements 
will support the Crisis Action System (CAS) and will empha- 
size such things as multi-plan support and no-plan support. 
The fcurth stage is Full Operational Capability (FOC) and 
the ICC is presently December 1985. Since JDS is the center 
of the Conventional Planning and Execution (CPE) functional 
family of the WWMCCS ADP program, the fifth stage, Post-FOC, 
will detail the JDS integration into the WIS modernization 
program. [Bef. 10; p. 78] 



39 



I 



Tbe JDS data bas€ presently contains 108 record types 
chained in logical record relationships in the Hcneywell 
Integrated Data Store (IDS) structure. The data includes 
informaticn cn forces, ncnunit personnel and cargo, rrove- 
nent , and transpcrta tion . The JDS is a ccnglomera ticn cf 
375 application programs and subprograms which maintain and 
manipulate the deployment data base. The majority cf the 
JDS software worlds or. me nu- selection and pre-defined display 
screens. Although the entire data base is resident at the 
JDA, various deployment community members will maintain 
separata data bases to satisfy unique command requirements 
and ccmmand and control functions. Each of these sites will 
also maintain a Data Ease Management System (DBMS) and local 
access to the main data base. These distributed data cases 
will be subsets of the master data bass and will be main- 
tained ccncurrently with the master by near-simultaneous 
(within five minutes) distribution of data transactions. 

This distribution will significantly reduce WIN activity and 
network performance degradation associated with large data 
transfers. The distributed data bases will also enhance JDS 
survivability by providing multiple backup locations for JDA 
functions. [Ref. 10; p. 25] 

E. FOBCTIONS 

One cf the major JDS functions is to provide a bridge 
between deliberate planning and time sensitive planning and 
execution. The two systems utilized during these procedures 
are the Joint Operational Planning System (JO?S) and the 
Unit Status and Identification Report (UNITRE?) System. 

JOPS establishes procedures for planning and executing 
deployments during peacetime and crisis situations as 
directed by JCS; the ONITRS? System contains the location 
and identification of actual military units needed during 
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the planning and execution phases of deploynient. <3BS 

supplies the necessary link between nhese two sysness by 
maintaining an up-xo-dane deployment data base. [Hef. 10: 
p. 9] Figure 3.2 graphically illusxrates the JDS ccnnecticn 
between deliberate planning and time-sensixive planning and 
execution. [Ref. 10: p. 10] 

During the deliberate planning phase, Time-Phased Force 
Deplcyment Data (TPFDD) files are developed for a specific 
Operation Plan (CPLAS) using JOPS and UNITRSP. The initial 
data is collected from supported commanders and service 
requirements. The JDA holds a two-phase conference for 
refinement of the data and then the TPFDD is incorporated 
into the JDS data base for that specific OPLAN. This method 
provides the primary source of inpux into xhe JDS. Seme 
problems with these procedures are the xime-consuming 
conferences and reviews and xhe manual manipulaxion of the 
data. [fief. 10: p. 12] 
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BEHOTE USES' S PACKAGE 



Since rhe aajoriny of JDS users are remors ar.d the File 
Transfer Service (FTS) on MIN has proven to be slow ar. d 
unreliable, the Joint Deployment Agency developed the Remote 
User's Package (BUP) to offset some of these problems. The 
RUP is installed at selected WIN sites to allevrate seme of 
the network overloading caused by large data transfers. 

When utilizing the Remote User's Package, no direct connec- 
tion tc the JDA host via WIN TELNET is required access 
the data base. [Ref- 21: p. 26] Since the SUP permits users 
to input update and query transactions via their own 
Time-Sharing system ITSS) and the data bass is then accessed 
through WIN, users experience a significant degradaticn of 
cwn TSS response time. The JDS Remote User's Package 
includes an Interface Processor (JDSI?) , an Update Processor 
(JDSUP) , a time-sharing package, and a batch update 
capability. [Ref. IS: p. 7 ] 

The JCSIP provides the necessary communications prctccol 
fer transaction processing between two WIN sites. The 
sending site JDSI? breaks bulk files into individual tran- 
sactions, then the receiving site JDSI? accepts eech 
transacticn and passes it to the JDS if a WIN cor.necti on is 
available or holds the transaction until a connection is 
made. An acknowledgement is necessary from the receiver 
before the next transaction (packet) is sent. The Remote 
User's Package essentially transforms the WWKCCS 
Int sreemputer Network into a transaction processnng system, 
as was the original design goal for WIN. The capabiltiy now 
exists for transacticn update processing between twe WIN 
sites in near- real time without dependence on a WIN 
connection to the JDS. [Ref. 19: p. 9] 
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The JESIF of th-s rsceiving site forV'ird3 one ransac- 
tions to tha JDS Update Processor (JDSU?) for individual 
inclusion into the data base. The J'DSU? is capable ci 
receiving input transactions from the time-sharing or batch 
systen, WIN via the JDSI? and ?TS capabilnty, and AUTODIN 
via the NACE processors. The Update Processor provides 
dynamic recovery check points during processing without task 
interruption. If necessary/ transaction processing recovery 
is achieved after a cemm uni cations interruption using these 
checkpoints, thereby no longer requiring tae complete 
reinitialization of the task. [Ref. 19: p. 9] 

Although JDA-generat ed software has greatly improved JDS 
performance, particularly in the WIN arena, additional 
improvements are necessary. JDS should be supported by 
software which requires a minimum amount of training and 
skills due to the computer experience of most users; for 
instance, JCS action officers. Users have recenmended "^-he 
information displays be modified to remove the time-frame 
distircticn cf ’deliberate’ or ’crisis' planning. Although 
the data is now maintained quarterly by the Command and 
Control Technical Center (CCTC) , part of DCA, the JDS 
deployment data base should move towards real-time mainte- 
nance tc constantly provide a current deployment situation 
data base resident at JDA. [Ref. 10: p. 13] 

Additional areas for general system improvement include: 

(1) revising man-machine interfaces fer simplifica- 
tion 

(2) aggregating information for senior level 
managers on general JDS capabilities 

(3) insuring mors accurate and timely data ccllec- 
t icn 

(4) developing standard data definitions 

(5) enhancing the recovery and backup facilities 

[Bef. 10: p, 19] 
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ggaCCS/JDS PSSFORa&HCE 



As prsviously discussed, -he informaiicn flow between 
the NCA and military forces depends upon a reliable, secure, 
and survivable intercomputer netvorfc. The Hwaccs 
Intercomputer Hetwork (WIN) was designed to provide exchange 
of information through computer- to-coaputer and remote 
terminal-to-computer processing using distributed data base 
concepts and workload sharing technigues. (Ref. 5: p. 42] 
KWaccS evclved through the early years as services developed 
hardware and software to meet unique requirements. Eased on 
the evolutionary approach to systemr: development, WWMCCS 
should evolve through requirements specifications as opposed 
to the traditional system acquisitio:: approach. This theory 
is supported by a lack of specific C3 system criteria; 
poorly understood C3 systems concepts; language barriers 
between the policy makers, planners, and commanders; and the 
nebulcus framework fcr C3 systems evaluation, [Ref. 5; p. 
16] There are numerous systems other than C3 systems which 
suffer from cne cr mere of the problems mentioned. For 
instance, any highly specialized system will likely experi- 
ence barriers among technologists and users. 

As proven with the early WWMCCJS, allowing users to 
develop small, unique systems independently, precludes the 
integraticn cf these systems into a responsive, larger 
system. Cbviously, interoperability was not the primary 
concern fcr these individual funding efforts. Twenty years 
later, WWMCCS remains somewhat fragmented due to the absence 
cf a centralized, long-range plan for the management and 
budget ccntrcl of WWMCCS and the Defense programs affecting 
WWMCCS. With the WWMCCS Information System (WIS) , a Joint 
Program Manager (JPM) Office was established to provide 



45 



cenx.rali 2 ed isanagsmcn- dor all aspects of the WHMCCS scdsr- 
nizaticn prcgram, 

A. SCFTSABE 

The ccmputer operating s:ystem utilized with the 
Honeywell equipment is the G;eneral Comprehensive Operating 
System (GCOS) designed by Honeywell. Honeywell also distri- 
butes this operating system to civilian customers but the 
Command and Control Technical Center must extensively modify 
each GCOS release for security additions and unique WWMCCS 
Software so the GCOS used within the WWHCCS community is 
consistently several years behind the current civilian 
version. GCOS was developed to support a single-sits and 
batch-oriented user community and has proven very successful 
in such situations. Present day C3 system requirements 
however, demand an online interactive processing capability. 
While modifications to the 1-oneywell hardware and software 
have improved performance, 1 he basic circuitry is designed 
for batch processing and optimal performance will not be 
achieved in an online interactive environment. 

With any large data bass system, a Data Base Management 
System (DBMS) will be developed to allow easy retrieval and 
updating of the data base. Generally, these management 
systems are user-friendly and require minimal technical 
expertise for successful use. The DBMS used with WWMCCS is 
the WWIiCCS Data aanagemer.t System (WWDMS). Since WWDMS 
resides cn the Honeywell equipment, it relies on the GCOS 
operating system; therefore WWDMS was designed around a 
batch-oriented architecture. WWDMS uses GCOS to access 
files for retrievals and updates. Because of the ineffi- 
ciencies of the military version of GCOS in transferring 
data in and cut of primary memory, the performance of WWDMS 
is adversely affected. (Ref, 5: p. 25] 
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Scporto on the user- fr i sndly aspect of WWDMS have r.cc 
teen favoratlsr For the most part, the HHDMS language is 
oriented towards the more technical personnel and is consid- 
ered too detailed for the average WWMCCS user with minimum 
computer training. Consequently, users are not likely to 
pursue the management system capabilities beyond standard 
procedures and Ww'DMS ' full facilities remained unused. For 
the ccmmunity to exp'.lcit the systems and capabilities avai- 
lable in MKMCC3, a user-friendly and responsive DBMS is a 
necessity. Since the concepts of a distributed databse 
management system are new, a reliable query language could 
suffice during the development interim. It should require 
minimum computer experience and a minimum amount of special 
training. 

The need for a Mtlti-Level Security system will not be 
satisfied utilizing the the current WWMCCS Honeywell equip- 
ment since this lesion incorporates only two machine states, 
cr rings. The rtaster state accomplishes the kernel func- 
tions of the operatirg system, password validation and data 
requests, as well as the functions for scheduling and allc- 
caticr cf resources. The second state is for user 
applications programs, referred to as the Slave state. 

[Bef. 5: p, 29] 

Since the security protection procedures, all system 
software, and the resource allocation procedures reside in 
the same ring, access to the specified ring area is common 
to all users with access to any one section of that ring. 

The current theory is that, under this scheme, any gccd 
systems programmer should be able to penetrate the kernel 
section and gain access to all passwords and security 
checking procedures. 

Security alternatives to a HLS system are dedicated 
ccmputers, scheduled operations, and system-high security 
cperaticns. With dedicated ccmputers, a separate computer 
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is rsQuirsd for sach security level and individual dera 
tasss are required fcr each application requireaenr wirhin 
the different security levels. The scheduled operarions 
merhod insures all dara per security level is processed at 
separate tines. This restricts users of different security 
levsls tc computer availability. The most difficult aspect 
to this nethcd of secure processing is the sanitization 
necessary between security level processing periods. The 
entire system envircrment must be modified, both the machine 
and physical facility. In addition, communications lines 
must he Lroken, disk packs must be exchanged for the diffe- 
rent security levels, and main memory cleared. This 
procedure averages one to two hours to complete. [Ref. 5: 

p. 28] 

The third alternative, system-high security operations, 
is primarily used throughout the wwaccs community. With 
systein-biah operations, ail personnel, physical space, and 
equipment must be approved for the aighest security level of 
the inforniaticn being processed. The biggest disadvantage 
to this method is the restriction it places on the sharing 
of secure cciputer resources. In addition, this method 
becomes costly in terms of physical security and personnel 
clearances. The system-high security approach, if imple- 
mented correctly, will satisfy security level requirements 
tut dees not address the need-to-know issue. [Ref, 5: p. 

28] 

£. BSB2WABE 

The availability of an electric power source greatly 
affects the reliability and survivability of a computer 
network such as the WWMCCS Intercomputer Network (WIN). For 
the current WIN, there exists nc standard criteria fcr the 
availability of electric power. If electric power is 
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disrupted cr the air-conditioning damaged, data processing 
capabilities are totally lost or, at a minimum, severely 
degraded. Only a few WIN sites have a reliable backup power 
source or redundant computer system. The National Military 
Command Center (NMCC) maintains two independen-^ power 
sources for its computer system. This system affords 
protection against various local power blackouts and irregu- 
larities in the commercial power system. [Ref. 5: p. 29] 

The NKCC also maintains a totally redundant computer system, 
hardware and software, located at the Alternate National 
Mili.tary Command Center (ANMCC) , which has an internal power 
generating capability. In early WWMCCS years, the ANMCC was 
considered hardened and fully self-supporting, but the 
alternate sits is no longer considered hardened against the 
current threat. A few other large WWMCCS sites utilizing 
comnisrcial power are also armed with an internal power 
generating capability, for instance, the North American Air 
Defense Command (NOSAD) and the Strategic Air Command (SAC) . 
Most other WWMCCS sites have no reliable backup power 
source. 

Presently the NMCC has, of course, the most viaole 
alternate computer system — both redundant and remote. 

Other sites maintain redundant data bases but usually in 
close proximity. For example, the Joint Deployment Agency 
maintains a backup JDS data base at the Readiness Command 
(E2DCCM) but which is physically located at the same 
facility. 

C. niY llAGDE 82 

During the period 1 March to 5 March 1982, the JCS 
conducted a WWMCCS exercise, IVY LEAGUE 82. The exercise 
was designed to evaluate defense operations run from the 
NMCC at the Pentagon, then relocated to the alternate 
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comaiand center, the ANMCC. As the exercise progressed, WIM 
perf orioarjce dropped and response times reached an 
unacceptable level. A DCA/CCTC sponsored IVY LEAGUE 
Analysis Task Force vas organized to analyze the performance 
of the WWKCCS ADP system and network, with concentration on 
the particular problems encountered during the IVY LEAGUE 
exercise. [Bef, 22: p- ] 

The Task Force focused its analysis on the four major 
sites where the slowdown condition was most prevalent: the 
NMCC Beadiness System, the ANMCC, REDCOM, and the JDA. 

These four sites were not all the WIN nodes participating in 
the exercise, but it was felt these sites were indicative of 
overall WIN perfcrmance during IVY LEAGUE 82. Information 
was collected from on-site exercise personnel, manual logs 
updated thrcughott the exercise, computer generated list- 
ings, and WWMCCS computer system console logs from the 
participating sites. [Sef. 22: p. v] 

The IVY LEAGUE Task Force revealed several major factors 
contributing to the win degradation: 

(1) excessive communications processor loading 

(2) communications subnetwork fragmentation 

(3) host computer resource contention 

(U) software resource contention 

(5) management of computer operations 
Each cf these will be discussed in the following sections 
with their impact on JDS performance. 

D. COHHUaiCATIONS P3CCESS0R LOADING 

The successful operation of the WIN network depends on 
an unconstrained flow of data between the computer system 
and the network. A communications processor is used on the 
network tc ccordinate inputs from remote terminals and send 
them to the host system; it also receives outputs frcm the 
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computer system and sends them to the correct user. The 
communications processor handles the connection from the 
host computer system to the networlt. The Honeywell Datanet 
355 (DN 355) is the communications processor used throughout 
the WWMCCS community. 

The design of the Datanet requires sufficient available 
memory to process message traffic; otherwise the Datanet may 
restrict the flow of traffic from the host to the network 
and from remote sites to the host through unsatisfactory 
terminal response time and slow file transfers. The block 
cf memory allocated for message processing is subdivided 
into sections called buffers. Buffer size is dependent on 
the type and number cf connections to the Datanet. Tne 
greater the number of connections, the lower the available 
memory and the lower the buffer size. MIN connections to 
the Datanet must contend for buffer space with remote 
processors, AUTOBIN connections, and the local terminals. 
CRef . 22: p. 2-1 ] 

During ivy LEAGUE 82, when the Datanet became over- 
loaded, users experienced up to ten second pauses for system 
response. Seme of this was attributaole to Datanet cver- 
conf icuraticn — too many connections to one Datanet. At 
JDA, all 115 local terminals and the MIN connection were 
served by the one Datanet. In some cases, several terminals 
shared one line into the communications processor which 
further hindered terminal response time. In addition to the 
terminal overloading, this same Datanet also served the 
AUTOCIN interface at all four sites reviewed. [ Bef . 22: p. 
2 - 1 ] With this Datanet configuration, any terminal discon- 
nect from the system or any Datanet failure affects all 
connected terminals, both local and remote. Considering the 
large number of terminals connected, the chance of a Datanet 
failure or system reinitialization (reboot) to clear 
terminal or KIN problems is extremely high. Figure 4.1 
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graphically depicts user-de pendence on the DN 355/Hcsr link. 

[Ref. 8: p. 3] 
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Figure 4.1 JDA Configuration. 

During periods of parricularly bad psrforniance in IVY 
LEAGUE 82, computer data dumps were taken from the REDCGK 
Datanet. JDA Datanet dumps were not available, but the 
REDCOM configuration was considered similar to that of JDA 
with 139 local terminals connected to the one Datanet. Data 
retrieved revealed 4,490 data transfer requests denied 
during a 17-hour period because of insufficient buffer 
space. During a separate 22-hour period, an additional 
4,651 data transfers were denied due to lack of buffer 
space. These numbers only reflect Datanet denials, local 
Interface aessage Processor (IMP) and terminal malfunctions 
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may also have occurred. During IVY LSAGUE 82# -,he JDi hcs*: 
computer received an average of 150,000 transact ions pa- 
day. Specifically, on 2 March, JDA processed 252,864 tran- 
sacticns and 87,417 transactions were processed on u March, 

[Ref. 22: p. 2-2 ] 

Another hinderance to Datanet performance was operator 
reboots of the Datanet. Operations would frequently reini- 
tialize the Datanet in an attempt to free blocked terrcinals 
or solve WIN protlems and various other abnormalities occur- 
ring in the network. [Ref. 22: p. 2-1] Although the 
specific impact cf these Datanet restarts were not analyzed, 
they obviously affected WIN performance. For instance, the 
Joint Deployment System tranfers TPFDD files and TPFDD tile 
changes tc remote sites through the WIN FTS. If a Datanet 
reboot occurs during this time, the file transfer must be 
recovered. Previous to the development of the Remote User's 
Package (SUP), transaction recovery meant file transfer 
reinitialization. Now, the JDS Update Processor (JDSUP) 
dynamically generates checkpoints throughout the transfer tc 
allow file transfer recovery at the point cf disccnnec" io t. 

The WWKCCS ccmmurity employs Datanet performance mcr.i- 
toring software to warn of possible Datanet overload. This 
monitoring software requires approximately 2,500 words cf 
memory which further reduces the Datanet memcry availaDls 
for message processing buffers. Consequently, at all four 
sites included in the analysis, the monitoring software was 
not in execution. [Ref, 22: p. 2-1] 

S. SETMOBK FRAGMENTATION 

As discussed in the previous section, the WWMCCS network 
is very susceptible to interruptions cccuring within the 
lines cf ccmmunica ti cns. Any network configuration changes, 
component outages, or circuit failures will cause 
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fragin€nt.aticn of the network inro subnetworks, thus 
degrading performance. [Ref. 22: p. 3-1] Each i?W?!CCS host 
computer involved in the WWHCCS Intercomputer Ke-^work is 
linked tc a Honeywell minicomputer called an Interrace 
Message Processor (IMP), and the various IMPs are then 
interconnected. 

During IVY LEAGUE 82, the Network Operations Center 
(KOC) and DCA Operations Center (DCAOC) were relocated no 
the alternate command center, the ANMCC. To provide 
continued support fcr these nodes on the win subnetwork, the 
master IMP, normally at the Pentagon, was logically reccn- 
figured tc the backup facility at the Command and Ccr.trcl 
Technical Center (CCTC) , Seston. Changes were necessary 
within the WIN subnetwork due to the backup IM?‘s limita- 
tions and circuit availability. The major modification was 
the deletion of the link from the master IMP to the I ■!? ai 
Headquarters, Atlantic Command. As the exercise progress ad, 
it became evident that the loss of this one particular link 
proved tc be a major factor in network fragmenta t i cn . 

During these periods cf fragmentation, the exchange of data 
between WIN sites was totally disrupted. [Bef. 22: p. 3-2] 

Although the IMP and circuit outages were usually short, 
these, coupled with the major configuration changes, 
severely degraded WIN performance. For instance on 1 March, 
88 circuit outages occured for a total cf 5.13 hours 
down-time. Later in the exercise on 4 March, a sum loss of 
7.72 hours was felt during 138 circuit outages. For the 
entire IVY LEAGUE 82 exercise, 476 line outages occured with 
65 extending over 10 minutes, 22 of these outages were *he 
result of required cryptographic key changes. Key changes 
were a frequent cause for circuits displaced from normal 
activities. IMP outages for the exercise totaled 334 with 
52 lasting ever 10 minutes: 77 at 6.63 hours on 2 March and 
82 at 7.62 hours on 4 March. [Bef. 22: p. 3-6] 
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BESODECE CONTENTION 



During IVY LEAGUE 82, nvimerous cas$s of host resource 
disuse occurred in areas such as primary memory allocaoion, 
job priority assignment, and improper implementaoion cf will 
software. These conflicts severely limited toe host sysrem 
performance. The Analysis Task Force studied these prctleras 
at the NMCC Feadiness and ANIICC computer systems only, but 
it was felt similar situations existed at numerous other 
wwaccs sites. [Bef. 22: p. 4-1] 

The NKCC WWMCCS site is segregated into tuo distinct 
computer systems: Readiness and Support. The Readiness 

System is designed fcr the operation of WWMCCS standard 
software and other site-unique software that has previously 
been tested and is new in production. The NMCC Support 
System is an identical configuration to the Readiness system 
and exists for the development and testing cf new software, 
Cr.ly the Readiness System participates rn JCS exercises as 
the Support System centinues to support daily operations. 
Priorities fall so that the Support Systei! may be sacrificed 
to maintain the performance cf the Readiness System. 

With only fully operational software allowed on the NMCC 
Readiness System, the percentage of aborted jobs is expected 
to be small. During the exercise, the amount cf computer 
resources expanded cr. jobs which ultimately aborted was 
unacceptably high. Some aborts were due magnetic tape 
and various ether hardware problems, out at undesirable 
number were caused by software still in the developmental 
stage. [Bef- 22: p- 4-2] Prior to a new WWMCCS software 
release, the tamptaticn for programmers to use the Readiness 
System as a testbed fcr application system modifications is 
high. The response time is decidedly better on the 
Readiness System because of decreased aborts and code optim- 
ization. Guidelines for testing state all systems resident 
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on the Readiness system no be tested and/or modified will be 
transferred to the Support System. After verification with 
the new WWMCCS software, the modified system will then 
replace the old systei on the Readiness computer. The idea, 
of course, is to preserve the Readiness computer in both 
time and space requirements for cris is/exercxse support and 
employ a second system for the heavy processing and tne 
usually large space consumption of software development. 

Beth systems studied, the N:!CC Readiness and the AN??CC 
system, suffered from a lack of availaole memory for 
processing. In particular, on 2 March memory shortages 
severely constrained processing capabilities for a five hour 
period. Under the current WWMCCS ADP, it is possible to 
dynairically reconfigure a system without completely bringing 
it off-line; for example, allowing the addition of memcry to 
the host computer system during an exercise. [Hef. 22: p. 
4-1] Although infrequently done, aemcr/ may be acquired from 
the NMCC Support System to improve the performance of the 
Readiness System. 

A standard WWMCCS program size is aipproximately 60K (60 
X 1024 bytes). Any one applied tic.:: program requiring mere 
than 60K cr a large amount of CPU time, should be remodeled 
to include code optimization and some method of memory 
overlays cr paging. [Ref. 22; p.. 4-1] 

In addition to large memory utilization, numerous jobs 
with high priorities running simultaneously will affect 
system performance. Honeywell supports an urgency system 
for determining job priorities -- urgencies may vary from 
zero to 63. Typically, urgencies of 30 and below are used 
for user application programs; for example, routine batch 
and TSS jobs are assigned an urgency of 5. Urgencies above 
30 are reserved for system software applications and special 
production runs. Urgencies higher than 50 support system 
programs such as TLCI, ?TS, and other WIN software. 

[Ref. 22: p. 4-2] 
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Sta~istics show approximately thirty percent of all 
activities processed cn the ANMCC comparer system during the 
exercise had urgency levels greater than or equal to rhe 
urgency levels of system functions. Software such as ISS 
and WIN have urgencies from 50 to 60 to allow primary access 
to the processor. During ivy LEAGUE 82, this software was 
competing with user application software for computer 
resources because of unjustified high user application 
urgencies. [Hef. 22: p. 4-1] 

The KWKCCS systeii console operator has the ability to 
override system prescriboJ urgencies. This is usually 
accomplished on a case by case basis for ad-hcc prcducticn 
runs. Any system requiring a large block cf memory, 
substantial CPU time, or lengthy input/output prccessinq 
will normally be awarded a lower urgency, causing it to 
remain in the system a relatively longer length of time. 

When the urgencies cf these systems are bumped to higher 
levels, whether justified or not, they compete with system 
software, usually large time-consuming systems themselves 
and the * molasses condition* occurs -- total system slow- 
down. An inordinate amount of automated bookkeeping is 
necessary for proper resource availability and the processor 
becomes overloaded. When this condition occurs, known as 
thrashing, the effectiveness cf the Honeywell urgency system 
drops to zero. 

The cumulative affect of all the above mentioned situa- 
tions equals increased user response time and user 
frustration. During normal NMCC operations, TSS response 
time averages five to seven seconds; during heavy usage, 
exercises or crises, response time increases incrementally 
by approximately three seconds until total system slowdown 
occurs. 
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MIN scf“ware is ret always the 'viceim' of poor WIN 
perf oxiBar.ce. Some software, both systems software ard 
applicaricr systems, contribute zo rhe increase in host 
system prccessinc requirements. When these requirements 
exceed system ca fabi lities , support of local and network 
operation decreases. 

Seme of the fcIN system software particularly affected by 
degraded network performance includes: 

(1) Teleconferencing (TLC?) System 

(2) File Transfer Service (FTS) 

(3) Talecommunciati ens program (T2LNET) . [Hef. 22: 

p. 6-1] 

The Teleconferencing capability in MIN allows users to 
rejoin the conference and request a transcript file of 
actions since that site's last log-on. These files are 
spooled to tne printer at a high urgency for speedy 
printing. Curing IVY LEAGUE 82, the large number of tran- 
script file requests severely impacted the performance of 
the system hosting the teleconference. 

The File Transfer Service employed in the MIN utilizes a 
dynamic memcry management scheme to maintain an available 
memory level between the minimum and maximum guidelines. 

The management system constantly allocates and deallocates 
sectiens cf memory as small as IK to sustain an acceptable 
memory level. This ccntinucus processing requirement places 
a heavy load on the host processor. Also, during a file 
transfer, FTS reads and writes one Little Link (LLINK) cf 
data at a time, 320 words. This limits possible transfer 
rates and FTS effectiveness. [Hef. 22; p. 6-1] 

TELNET uses software similar to the FTS memory manage- 
ment software. Although this imposes additional loading on 
the processing system, the contribution to system leading is 
not as significant as FTS or TLCF. [Ref. 22: p. 6-1] 
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JES BES0DHC2 CONIENTION 



Larg€ software applications used over the WWMCCS 
netwcrx, such as the Joint Ceploymenr System, need rc be 
concerned about resource requirements and operational effi- 
ciency. Since such a wide degree of diversify exisns among 
application systems, no guidelines for szandardization of 
new KiJilCCS software have been established; therefore, these 
issues are left to the developing agency. For instance, the 
Joint Deployment System maintains two interactive subsys- 
tems, the JDSIP and JDSUP as part of the Femote User’s 
Package (SUE). The Analysis Task Force contends these two 
subsystems fail to taka the best advantage of the standard 
wwaccs software features and consequently generate substan- 
tial overhead for the processor. After analysis of IVY 
LFAGUr. 82, the need was evident to redesign portions of the 
JDS software to insure more efficient processing and 
overhead minimization. [Ref. 22: p. 6-3] 

The operation of the JDSIP caused noticable degradation 
durinc the exercise. The Interface Processor subsystem 
requites 28K to process and runs with an urgency of 51. The 
JDSIP will remain in memory as long as it is processing 
transactions. When the processor is not required, i.e., no 
transactions to be processed, the JDSIP will place itself in 
a ’sleep state' — degrading its urgency to zero which 
immediately allows it to be swapped out of the system at the 
next memory allocation request. Actually, this should be 
very efficient use of memory, or at laast 28K. The problem 
arises in waking up the JDSIP. Since the subsystem has no 
means of determining when the next transaction will be 
received, the JDSIP periodically, about every two to three 
seconds, resets its urgency back to 51 which returns it to 
memory where it can check for transactions to be processed. 
If no transactions are waiting, the urgency is rsturned to 
zero and the cycle repeats. [Ref. 22: p. 6-3] 
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This scheme is at its worst when JDS is rarely used on a 
given system. The JESIP simply fluctuazes from mass srcrage 
to primary memory with no advanzage. This swapping back and 
forth creates unnecessary overhead processing and can seri- 
cusly degrade network performance. Casa in point; cn 1 
March, during IVY LEAGUE 82, the JDSI? was swapped a total 
cf 412 times in an eight-minute period, from 1355 to 1403. 
(Ref. 22: p. 6-3 ] 

The JDS Update Processor (JDSU?) poses a similar situa- 
tion. The JDSUP requires only 9K to process and runs at an 
urgency cf 55. During certain processing periods, the JDSU? 
must request a single block cf 50K of memory. When this 
request enters the system, the system will immediately rear- 
range its memory to accommodate the request from such a high 
priority job. Usually, a system interruption is evident. 
After the JDSU? has ccmpleted that process, the 50K is 
returned to memory; however, the JDSU? in general iramedi- 
a*ely asks for another single block of 50K to continue 
piocessrng. [Ref. 22; p. 6-3] 

The allccaticn and deallocation of this 50K of memory 
proved tc be detrimental during the IVY LEAGUE exercise. On 
2 March, JDSUP requested 50K at 0120, released the raemcry at 
0'I22, and requested another 50K block at 0 125. This cycle 
ci request-release-reguest was repeated during the 0330-0340 
time pericd that same day. [Ref. 22: p. 6-3] 

H. MA8AGEHEHT OF COMPUTER OPERATIONS 

During IVY LEAGUE 82, it became evident that hardware 
and software problems were net entirely responsible fer the 
C3 system degradation. The overall management and control 
of the network and host system also contributed to deficient 
performance . 
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As part of the normal operations of all WIN sites, hard- 
ware such as the host computer system, the Datanet, and the 
IMPS are reinitialized in an attempt to solve various prob- 
lems. These reboots interrupt network performance ana can 
impact local user operations. In addition to unexpected 
down time and reboots, scheduled outages occur at all sites. 
Ihe WWMCCS community has no standard guidelines for the 
scheduling cf these cutages. Frequently, these unscheduled 
downtimes are not justified; for instance, during the exer- 
cise, a Catanet was rebooted to allow a single user access 
to a particular system for a local processing requirement. 
This reboot affected all users on that subnetwork. 

On 3 March, the ANMCC discontinued service to remote 
users because of an apparent memory shortage problem. 
According to VIDEO, an online display system which allows 
monitcring cf system status, minimum work was being 
processed because of a lack of available memory. The after 
exercise analysis however, revealed approximately 150K cf 
memory available during that time frame. The discrepancy 
occurred due to improper use of the VIDEO system. This 
system is designed tc provide an instantanecus picture cf 
system resources. The system was likely restructuring 
memory ic accommodate the increased workload when the deci- 
sion was made to detach all remote users. [Ref. 22: p. 5-2] 

Another operational contribution to poor network perfor- 
mance occurred when ITS was used to transfer files around 
within the same site, as opposed to using a COPY utility. 
Transferring a file with sending and receiving sites speci- 
fied as the same site, sends the file to the local IMP which 
immediately returns the file to the same host. During IVY 
LEAGUE 82, exercise statistics showed that 34^ of all file 
transfers at the NMCC were same-site transfers, as were 67% 
cf Military Airlift Ccmmand (MAC) transfers and 83% at the 
WWMCCS site supporting the Ccmmander-in-Chief , Naval Forces 
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Europe. [Ref- 22: 
wastes host system 



p. 5-3] This type of funcrionai misus 
resources and contributes to MIN load 
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BECOBMEN DAT IONS AND CONCLO SIO NS 



When the current HWMCCS/WIN management problems are 
addressed during the modernization phase, network perfor- 
mance should improve. This will decrease user frustration, 
especially during high volume times, and increase user 
activity on the system. This increase in volume in turn, 
may affect system performance and, with greater user carti- 
cipaticn comes additional site- unique software. Site-uniqu« 
applications are created due to deficiencies within the 
system which will always exist in a system as large as 
WWMCCS. The WIS modernization plan doss not propose to 
eliminate this unique category of WWMCCS software, just 
minimize its proportion to standard software. 

A. SCFTHARE 

The 5iIS modernization plan includes a new operating 
system release, GCOS 8.0, and a modified Honeywell main- 
frame, the H6000 Distributed Processing System (DPS) . 

The majcr software modifications include: 

(1) improved data management and timesharing 
processing 

(2) BPS software written in a high order language 
which facilitates maintenance and modifications 

(3) increased number of timesharing users from 200 
to 600 

(4) increased number of concurrent processes frcm 64 
to 511 [Ref. 23] 

Net mentioned in the WIS modernization plan is any just- 
ification that this increase in possible user activity will 
not further degrade system performance. Although a new 
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processor is under consideration, the a6000 DPS mcditica- 
tion, a significant increase in processing capability is 
already critical to maintain availability of present Wr'HCCS 
software. Increasing the number of time sharing users 
three-fold will cuickly com sums any available processing 
time . 

The HWMCCS mcderniza tion plan also includes the C‘i4 
software package for better file management, allowing diffe- 
rent file structures for files in the same data base, and an 
enhanced DBMS, the Integrated Data Store II (IDS II). With 
the current IDS I, the progammer is not independent cf the 
data base -- one of the fundamental requirements or a Data 
Ease Banagement System. When using IDS I, the user iiust 
know the data base layout, referred to as the schema, and 
must include various system routines to successfully update 
the data base. IDS II will be more of a true DBMS, ailcwitig 
user independence from the data base schema. 

With a true DBMS, mors users are likely to p-ursue infcr- 
maticn contained within the system, thus increasing user 
retrievals from remote sites, i.e., retrieval requests frcin 
the JCS, and increasing data transfers on WIN. Again, the 
WIS modernization plan lacks an apparent knowledge cf new to 
handle this increase in activity. 

Although the basic software design of the WNMCCS equip- 
ment is inadequate fen a Multi-Level Security (M LS) system, 
there has been a proposal using hardware modifications. 
Honeywell has developed a system, the Honeywell Secure 
Comm unicatiens Processor (SCOMP) , which runs on the 
Honeywell Level 6 minicomputer and is billed as a MLS 
system. SCOMP utilizes four rings of protection with the 
kernel residing in Ring 0 and the least priviledged ring, 
Bing 3, belonging to the users. But SCOMP also modifies the 
hardware by supplying a hardware segmentation capability for 
dividing main memory into distinct logical (net physical) 
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areas. This should allow access checicing cer segnier.t fcr 
read/write priviledges, thus maintaining ccntroUsd software 
sharing among many users. [Ref, 24; p. 4] 

While SCCMP has not been fully validated by the COD 
Computer Security Center, part of the National Security 
Agency (NSA) , it is considered a large step towards the 
secure, time-shared computer resources needed in ccmmunit ies 
such as the WWMCCS ccmmunity. In December 1931, the 
security center published a Product Evaluation Bulletin 
specifying that SCOJJE ”... should be considered an accep- 
table candidate for a wide range of minicomputer 
applications which require an enhanced architecture to 
suppcrt secure processing requirements.” [Tisf. 25] 

Another emerging alternative is the BLACKER Technology. 
BLACKER will supply end-to-end encryption through the 
BLACKER Terminal Access System (TAS) . This lAS is a PD? 
11/70 or PDF 11/34 and acts as a buffer between the network 
and host computers fcr security verification. Upon Icg-cn, 
each user will be assigned a one time key for the life of 
the terminal session. These keys will be checked and veri- 
fied hsfcre access tc each data base is allowed. They will 
also be used to control inadvertent misrouting of iata, 
referred to as spillage. [Ref. 26; p. 6 ] 

The main idea behind the BLACKER prototype is tc allev- 
iate the burden of nrmerous passwords for each user per each 
host computer. Passwords are no longer considered secure 
for seme classif icat ion levels because they must be stored 
within the computer system and users frequently violate 
security prccedures by writing them down. One of the most 
viable alternatives proposed has been the use of magnetic 
strip identification badges and electronic badge readers. 
This system would allow for minimum manual intervention. 
[Ref. 26; p. 17] 



65 



t. 

I 

r-i 

>' 

I 

I 

p 

i 

■ 'f—' 

L 






i 



A MLS system would allow -he Joint Deployment Agency lo 
control access tc various capabilities in specific CFLAMs. 
Presently, all host computers and personnel must be cleared 
to the highest security level of any piece of data contained 
in the OFLAN. 

Functioning without a MLS system, full utilizaticn of 
WWMCCS resources is improbable and the sharing of computer 
resources over the network is restricted. During the 
interim between the present security procedures and the 
eventual development of a MLS system for ^WMCCS, the HIS JPM 
becomes the central WWMCCS security officer to standardize 
physical security procedures and set guidelines on the 
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same machine 
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having a reliable backup power source, the network should 
not be considered survivable. 

Included in the rear-term HIS modernization program is 
the procurement of the Honeywell 6000 Distributed Processing 
System (DPS) modification. The H6000 DPS offers major hard- 
ware and software improvements over the H606Q' and H608C 
equipment currently used in the HHMCCS community. Major 
hardware changes include: 

(1) 70^ to 90 % increased processing speed 

(2) space, pcwer, and air-conditioning requirement 
red uct ic ns 

(3) three-ring architecture for MLS system pcssi- 
tility [Hef. 23] 
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Tk€ Hcn=ywell aainfrases prasently ussd are fas~ 
approachir.g tha age cf computer antiguicy. The largesc 
problem centers around the Honeywell architecture which was 
not designed to support an online, inreracrive envircnment. 
Hhen hardware replacement is considered, nhe wwaccs host 
computers should be replaced v,ith computer systems designed 
to support a real-time, online, inceracrive environment. 

The changing requirements for :is*wor!< software, moving 
this software onto the Datanet processors, and advancements 
in computer technolcgy have all reduced the mainframe 
requirements for most W*?HCCS sites. For hardware acquisi- 
tion, WWMCCS sites will consider a series of minicomputers, 
for instance the Honeywell Level 6 minicomputers, versus cne 
large machine. Of ccurse, each site would be unique in 
configuration but a typical W'w.’^CCS site could employ cne 
Level 6 fcr each of the following i'unctions: the AUTCCIN 

message processing, the WIN connection to include handling 
TLCF support, the ADELO functions, and ail resident data 
bases and local processing requirements. 

C. CCHMONICATIONS PHOCBSSOH 

The «WMCCS community has com mun icaticns processor mcni- 
toring software which consumes 2,500 words of Datanet memory 
when implemented but can supply valuable information on 
Datanet overload situations. The implementation of this 
monitoring software for the Datanet is not a requiremen-^ for 
WIN sites, but each site should perform a trade-off analysis 
on memory required and information received. The statis- 
tical output from the monitoring software could reduce 
Datanet reboots by notifying operators of potential weak- 
nesses in the system; i. e. , running out cf buffer space fcr 
message processing cr the number of transfer denials 
exceeding an acceptable level. If memory space cannct be 
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supplied during a crisis/sxercise siruarion for the moni- 
toring software,, controlled simularions using the Dataner 
tDonitcring software should be implemented to forecast poten- 
tially threatening process combinations to the Datanet. 

A set of standard system guidelines should be developed 
for use at ail 5iIN sites to establish acceptable criteria 
for Eatanet reboots. Fr«iguent rebooting as a first try at 
solving a network problem should be discouraged. 

Also, a WIN software validation package should be devel- 
oped to prohibit file transfers within the same site. 
Included should be installation checks to insure WWMCCS 
Standard System Software is installed properly and site 
options are set at tbe prescribed level. [Bef. 22: p. 7-4] 

The Eatanet cvsrconf iguration problem, i.e., 115 termi- 
nals linked to one Datanet at JDA, lends itself to two 
recommendations. The first solution is simple but rather 
expensive -- procure more Honeywell Datanet 355 processors. 
Ideally, this would allow one Datanet to be dedicated to 
that site's WIN connection. This configuration would reduce 
WIN problems associated with cperator reboots of the Datanet 
to solve ncn-WIN problems. [Ref. 22: p. 2-2] With addi- 
tional Datanets, user load could be better distributed and 
Datanet failures would have less impact on the site perfor- 
mance. At a minimum, sites should avoid linking high volume 
connections such as kin, AUTODIN, and the JCS AD? Liason 
Officer (ADPLO) terminals on the same Datanet. In addition, 
sites should adhere to the standard WWMCCS loading levels 
for the Datanet as directed by the WWHCCS ADP Advisory 
Kemorandum (WAAM). 

The second recommendation is to eliminate the HoneywoH 
communications processor equipment and transfer these func- 
tions either to another vendor communications processor or 
to a minicomputer, such as the Honeywell Level 6 minicom- 
puter. The Honeywell Datanet 355 is limited in a memory 
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size which is no longer sufficiant for the normal massage 
processing capaciry ?.•: large WIN sites. Using the Laval 6 
minicomputer in series would alleviate the memory prcblems 
and provide additional processing capabilities. 

D. SETWOFK FBiG MENTATION 

Tc prevent the reoccurrence of problems similar to the 
ones caused by the Master IMP being reconfigured during IVY 
lEAGUE 32, contingency plans should be devised to eliminare 
the drastic configuration changes as were necessary when 
such a targetable IMP was deleted from the network. Srudies 
and crisis/exercise acniroring should be undertaken to 
predict possible circuit or IMP links which could initiate 
network fragmentation. [Ref. 22: p. 3-9] After identifying 
these areas, they should be reinforced during high volume 
times by redundant configuration or specific rerouting 
algorithms. 

After the C/20 switch upgrade, part of the WWMCCS moder- 
nization plan, IMP and circuit outages should decrease. The 
C/30 switch will provide tandem processing of up to 300 
packets per second, for a total of 900 packets being 
processed. Routing and rerouting will be accomplished by 
adaptive routing algciithms which will reroute individual 
packets tc the shortest path. In addition, monitoring and 
control functions are included to provide fault isolation 
and hardware and software problem diagnosis. 

Replacing the huge WKMCCS network with a series of Local 
Area Networks (LANs) will alleviate some of the degradation 
felt during network fragmentation. Moving the ne*wcrk soft- 
ware from the Honeywell mainframes onto the Datanets is the 
first step in building independent LANs. Eventually, all 
netwcrk software should be moved, alleviating the mainframe 
from any network control responsibilities. This would 
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rsiaov€ the restricticn for standard hardware for all WIN 
sites. With no standard hardware li mira tions , users could 
ta:,lor the acquisition of new hardware around specific sire 
requirements. Since all host systems will be linked through 
a coalmen network, minimum compatibiliry problems should be 
experienced . 

E. BESOOECE CONTENTION 

One popular recommendation for the mainframe processor 
contention problem is the addition of another processor for 
the NHCC Readiness System. This additional processor would 
be jusnif Led during an exercise but nor fully urilized 
during daily operations. 

As opposed to procuring an additional processor, the 
Support S'^stem cculd be modified ro temporarily provids the 
necessary h ardware/seftw ar e equipment during crisis/exercise 
situatiens. The mair advantage to this plan is reduced 
swapping for CPU contention. [Ref. 22: p. 4-3] The validity 
of this p].an is somewhat questionable. Previous to the SHCC 
WWMCCS computer system division into' Readiness and Support 
systems, there was a H6080 machine with two processors. CPU 
cenrentior reached a level to warrant the separation of 
produrticr. and development efforts, thus was born another 
computer system strictly for developmental efforts. 
Configuration now stands at two separate systems with one 
processor each. As mentioned in a previous section, users 
do not always respect the guidelines for use cf these twe 
systems. In light cf user-inducsd problems affecting 
performance, stronger enforcements of implemented procedures 
would be more cost-effective. The recommendation for an 
additional processor is expensive whether the dollars are 
spent actually procuring another processor which will be 
fully utilized only about twenty-five percent of the time or 
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the Support System software is used for high- priori* y usage. 
During the larer option, numerous software development 
personnel with no planned participation in a crisis/exsrcise 
environment, would be without a computer processor which 
greatly restricts their developmental efforts. 

Also hindering processor performance is ~he Honeywell 
urgency scheme for processes. The basic idea of the 
Honeywell urgency scheme is acceptable. The urgency scheme 
needs adjusting and the implementation should be modified 
for tighter controls on the system console opera'^or's 
ability to override the system default urgencies. Also, 
enhancements to prohibit application software from reaching 
urgencies in the WIN software level is necessary. This 
would discourage resource competition and improve system 
slowdown. One urgency system recommended included net 
allowing any application software to exceed an urgency of 
10. Few users, mostly system programmers, would operate at 
urgencies of 30 to 40 and no users would exceed 40. This 
proposal leaves urgencies of 40 to 63 for system software 
and WIN software. 

A new TSS Monitor has been developed within the WWMCCS 
community. This monitoring software is easy to use via 
system console commands and no system interruption is exper- 
ienced. Onfertunately, this new Monitor was not operational 
for IVY LEAGUE 32; but it can be utilized during the next 
exercise for selected small periods of time to allow a more 
thorough analysis of slowdown periods. [Bef. 22: p, 4-4] 
With the WIS modernization plan, the capability to monitor 
each network alement is achieved through the Monitoring 
Centers of the DDN. DDN will also provide an automatic 
fault recognition and isolation for trouble spots with most 
reconfigurations being handled without dedicated personnel. 
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WIN soft-ware, such as the aisaory aaanagement algori~hins 
for FIS and T3LNET, should be redesigned to reduce “he allo- 
cation and deallocation processing for memory. One 
alternative could be a minimum size of memory allowed for 
allocation, this would eliminate the overhead generated in 
the swapping of IK, 

Addit icnally , improved operational procedures are needed 
concerning teleconferencing transcript files. Options avai- 
lable include: 

(1) spooling the printed output with a lower urgency 
which would force printing at less critical times 

(2) aid. owing printing of the transcript file 
requests only during scheduled time periods 

The resource contention problem, especially at the NMCC, 
is stated as a top priority of the WIS modernization plan; 
however, no tangible alternatives have been proposed. 

F. JDS BESCOBCB CONIENTION 

The niemcry chasing problems of the JDSIP and JDSD? 
subsystems may be approached from several alternatives. 
Obviously, the aiount of al loca tion/deallocaticn depends 
almost entirely on the idle-time of the subsystem. Studies 
should be conducted at each site supporting the Remcte 
User's Package (5U?) to determine rts use/idle ratio. If 
the JDSIP subsystem remains in memory the majority of the 
time, minimum overhead is generated. If the JDSIP use/idle 
ratio is small, significant overhead will be generated by 
the subsystem changing urgencies to engage placement in core 
and the chance of checking for transaction activities. An 
alternative would be the development of a small check- 
routine tc permanently reside in primary memory. Its job 
would be to periodically, every two to three seconds, check 
for incoming transactions and change the JDSIP urgency to 51 
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if transactions .ars availabls for processing, at the saine 
tiae chancing its own urgency to zero. This would produce a 
sleep state sirailar to that of the JDSI? when inactive, only 
the check-r cutine would not leave core. When the JDSIF 
finished the necessry transaction processing, it wculd 
decrease its urgency to zero and change the check-routine 
urgency tc 51. This would allow the JDSIP to be swapped to 
mass storage at the next memory request and the check- 
routine wculd have high priority for processor time and 
resume waiting for the next transaction. 

Another alternative to be considered is the permanent 
allocation cf 2fiK to the JDSIP. This would allow the JDSIP 
permanent residence in primary memory and is feasible if the 
host system is not memcr y- r estricted . 

The JCSUP subsystem remains in primary memory itself at 
9K but periodically requires an addition 50K for processing. 
Part cf the problem concerning the JDSUP memory allocation 
stems frcj' the J?S0P requiring one single block cf 5CK cf 
memory. Generally, rhe system must rearrange memory to 
create a. contiguous 50K block. The easiest soluticn wculd 
be the permanent attachment of the 50K to the JDSUP 
subsystem. For a system memory-restricted at all, this 
alternative is impractical. A more feasible alternative 
would be to include 50K in the system size for the JDSUP and 
treat the 59K as one system. Then modify the JDSUP to 
reside on mass stoarge and utilize a check -ro utine , similar 
to the JDSIP, for dynamic checking of requirements. The 
same urgency swapping and processing schemes could be 
utili zed . 

In addition to the specific modifications to the JDS 
subsystem, several other measures could be taken tc improve 
WIN resource requirements: 

(1) development cf standards for new application 
software 
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(2) standard criteria for resource requiremerrs in 
new software 

(3) code optimization and memory overlays for larger 
systems 

(4) utilization of data compression techniques 

(5) improved input/output interfaces 

(6) more efficient data transaction activites 

(7) elimination of large data transfers 

G, CCNCLDSICNS 



Cne of the largest problems with the Defense Data 
Network (DDN) will be the Ilulti-Level Security issue. with 
the variety of users linked through cne common network, a 
tfLS system will be imperative. 

Anctuer DDN concern is the standard data communications 
protocols. These protocols should not only interface with 
the yWMCGS sites, but should be able to interact with NATO 
systems ;;or greater interoperability. The WIS J?M presently 
intends tc require standard protocols be written in the new 
COD design language, ADA. While no ADA compiler has been 
fully ce::tified as meeting all DOD standards, the step 
towards standard software should begin at software 
cone 2 pticn. 

The WIS modernization plan will bring modern software 
and later hardware into the WWNCCS community. The WIS JPM 
strategy is to tackle the software problems in WWMCCS first 
and bypass the fast meving technology field of hardware 
until later. Not all of the WWNCC5 standard software needs 
rewriting and by modernizing the software first, the WWNCCS 
network will become more adept to present day requirements. 

WSMCCS ADP problems will not be solved by the WIS meder- 
nizaticn plan or hardware changes alone. The WWMCCS 
computer systems are used for war-gaming and software 
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devalcpmenr but rhe primary intsnxion of this C3 systsm 
surfaces during crises with the handling of message traffic. 
The heart of the WWMCCS ADP program raus* be a fast, reliable 
and secure transaction processing system. Faster rcuring 
algorithms must be developed and improved physical surviv- 
ability is critical. Now, every node on the WWMCCS network 
is vulnerable to easy destruction and each node lost has a 
great impact on total system performance. 

The WIS modernization plan with an improved DBMS, 
management and security procedures, and user interface is a 
significant start towards the remodeling of WWMCCS. The 
modernization is planned over a ren year period and a major 
concern will be maintaining service dollar support. 

The Joint Deployment System will certainly benefit from 
the WIS icdernization plan. But the areas of network 
management, multi-level security, and resource contention 
must he addressed by the modernization plan and alternatives 
proposed. In the meantime, the Joint Deployment Agency will 
continue to develop JCS-uniqus software to supplement WWMCCS 
capabilities and provide deployment information through 
crisis situations. 
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